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EXECUTING  TRACE  SPECIFICATIONS  USING  PROLOG 


INTRODUCTION 

The  trace  method  of  software  specification  [1]  has  a  formal  foundation  that  supports  unambiguous 
specifications  susceptible  to  rigorous  proof  techniques.  The  method  is  also  abstract  and  produces 
specifications  that  neither  make  unwanted  design  decisions  nor  force  the  programmer  to  glean  essential 
program  features  from  a  mass  of  extraneous  clutter.  Its  formal  foundation  renders  traces  superior  to 
English-like  specifications,  and  its  abstractness  renders  them  superior  to  procedural  specification 
languages. 

A  disadvantage  to  formal,  abstract  specifications  has  been  their  opacity  to  programmers  who  use 
procedural  languages.  To  aid  the  programmer,  we  think  software  tools  are  needed  to  support  program 
development.  An  important  tool  is  a  rapid  prototyping  system  that  enables  programmers  to  check  what 
is  required  by  a  given  specification  and  users  to  check  that  what  is  specified  is  what  they  really  want. 
This  report  describes  the  approach  we  are  taking  to  build  a  system  that  translates  trace  specifications 
into  programs.  First,  we  provide  an  introduction  to  trace  specifications.  Next,  we  describe  a  general 
structure  for  a  system  for  executing  such  specifications  and  discuss  several  alternative  approaches  for 
building  such  a  structure.  We  then  give  reasons  for  using  Prolog  and  present  some  example  trace 
specifications  with  their  translations  into  Prolog.  Finally,  we  develop  an  implementation-free  semantics 
for  a  subset  of  Prolog  that  helps  us  address  the  possibility  of  mechanically  translating  trace  specifica¬ 
tions  into  Prolog. 

TRACE  SPECIFICATIONS 

A  trace  specification  for  a  module  consists  of  two  parts:  (Da  syntax  section  that  gives  the  pro¬ 
cedure  names  and  types  the  module  comprises,  and  (2)  a  semantics  section  that  gives  the  behavior  that 
the  module’s  procedures  must  exhibit.  Procedure  behavior  is  given  by  listing  assertions  that  describe 

the  behavior  of  sequences  of  procedure  calls,  written  co//i  _ call„,  known  as  traces.  The  assertions 

are  based  on  first-order  logic,  supplemented  by  the  predicate  L  that,  when  applied  to  legal  traces 
(traces  that  do  not  cause  an  error),  is  true,  and  the  function  V  that  when  applied  to  a  legal  trace  ending 
in  a  function  call,  gives  a  return  value  for  that  trace.  The  null  trace  is  always  legal.  Two  traces  S  and 
R  are  equivalent,  written  S  =  R,  when  they  are  indistinguishable  as  far  as  L  and  V  are  concerned  with 
respect  to  future  program  behavior.  More  formally,  S  =  R  if  and  only  if  for  any  trace 
T,L(S.T)  iff  L(R.T)  and  for  nonnull  T,V(,S.T)  =  V{R.T),  if  defined. 

As  an  example,  consider  the  following  specification  for  a  stack  of  integers: 

STACK  SPECIFICATION 

Syntax: 

PUSH:  integer 
POP: 

TOP:  —  >  integer 
DEPTH:  —  >  integer 
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Semantics: 

(1)  L(T)  -  L(T.PUSH(n)) 

(2)  T.DEPTH  =  T 

(3)  T.PUSH(n).TOP  =  T.PUSH(n) 

(4)  T.PUSH  (n).POP  =  T 

(5)  L(T)  -  V(T.PUSH(n).TOP)  =  n 

(6)  V(DEPTH)  =  0 

(7)  L(T)  —  V(T.PUSH(n).DEPTH)  =  1  +  V(T.DEPTH) 

The  syntax  section  says  that  the  stack  module  consists  of  the  procedures  PUSH,  POP,  TOP,  and 
DEPTH.  PUSH  takes  an  integer  as  a  parameter,  and  TOP  and  DEPTH  return  integers.  The  first  asser¬ 
tion  of  the  semantics  section  says  that  if  a  trace  is  legal,  then  one  can  legally  append  a  call  to  PUSH  to 
the  trace,  i.e.,  one  can  legally  push  any  integer.  Assertions  (2)  to  (4)  say  that  certain  procedure  calls 
do  not  alter  future  program  behavior  with  respect  to  a  trace.  In  particular,  assertion  (4)  says  that  a 
PUSH  immediately  followed  by  a  POP  has  no  effect  on  the  state  of  the  module.  The  fifth  assertion, 
when  accompanied  with  previous  assertions,  says  that  TOP  returns  the  last  item  pushed  on  the  stack 
that  has  not  been  popped.  Assertions  (6)  to  (7)  say  that  DEPTH  returns  the  depth  of  the  stack.  The 
reader  interested  in  a  more  detailed  exposition  of  traces  and  their  formal  foundation  is  directed  to  Ref. 
[11. 

We  can  derive  the  legality  and  value  of  a  specific  trace,  say  PUSH(5).TOP,  from  the  specification 
as  follows: 

(i)  L  (PUSH  (5))  Iby  assertion  1  and  the  legality  of  the  null  trace) 

(ID  PUSH (5). TOP  =  PUSH (5)  (by  assertion  3) 

(ill)  L (PUSH (5)  .TOP)  (from  lines  (I)  and  (ID  and  deHnition  of  equivalence) 

(iv)  V (PUSH (5). TOP)  =  5  (by  assertion  5  and  legality  of  the  null  trace) 

STRUCTURE  OF  A  SYSTEM  FOR  EXECUTING  TRACE  SPECIFICATIONS 

Our  goal  is  to  develop  a  system  that  will  accept  a  trace  specification  and  a  specific  trace  (or  traces) 
r  as  input.  As  output,  it  will  provide  L(r)  and  K(r)  as  defined  by  the  specification.  Graphically  it 
might  look  like  this: 


trace 

specification 


map  spec  to 

execute  spec 

executable 

target 

on  target 

form 

language 

machine 

(Phase  I) 

(Phase  II) 

specific 
trace  T 

L(T),V(T) 


The  choice  of  the  target  language  is  significant.  If  a  conventional,  procedural  language  (e.g.,  For¬ 
tran,  Pascal)  were  chosen,  the  Phase  1  task  would  require  translating  the  nonprocedural  trace  specifica¬ 
tion  into  a  procedural  form— a  substantial  undertaking  not  certain  of  success.  If,  on  the  other  hand,  a 
target  language  can  be  chosen  in  which  the  expression  of  a  trace  specification  is  relatively  straightfor¬ 
ward,  but  which  still  admits  of  execution  in  Phase  II,  the  Phase  I  task  is  greatly  reduced.  Languages 
such  as  Prolog,  LISP,  SNOBOL,  and  their  relatives,  and  the  input  languages  for  YACC  and  the  Boyer- 
Moore  Theorem  Prover  fall  in  this  category.  In  this  section  we  consider  briefly  the  effect  of  choosing 
each  of  these  alternatives,  and  explain  why  we  have  proceeded  with  initial  experiments  in  Prolog. 
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Approaches  considered  include: 

YACC.  YACC  is  a  Unix-based  compiler-compiler  I2l  that  accepts  grammar  rules  in  BNF  and 
semantic  actions  in  C  as  input,  and  generates  a  compiler  for  the  specified  language  (also  in  C)  as  out¬ 
put.  An  approach  that  uses  YACC  would  call  for  construction  of  a  YACC  program  that  could  accept  a 
trace  specification  and  generate  a  compiler  for  that  specification.  The  compiler  would  execute  in  Phase 
II  to  parse  incoming  traces  and  provide  values  of  L  and  V  as  output.  A  YACC  program  to  translate 
traces  into  Prolog  has  been  written.  Some  difficulties  were  encountered  in  constructing  a  grammar  for 
input  to  YACC  that  would  guarantee  recognition  and  reduction  of  traces,  but  investigation  of  this  alter¬ 
native  is  continuing. 

Boyer-Moore  Theorem  Prover.  This  is  probably  the  most  capable  automated  theorem  prover 
currently  available  (31.  If  trace  specifications  could  be  translated  into  axioms  for  the  theorem  prover, 
the  prover  could  be  used  to  check  the  value  and  legality  of  a  given  trace.  The  Phase  I  tool  would  have 
to  handle  the  translation  of  trace  specification  into  the  proper  input  notation  for  the  theorem  prover. 
Discussions  with  Moore  about  the  learning  time  needed  to  become  facile  in  the  use  of  the  prover 
(approximately  six  months  for  a  logician)  led  us  to  discard  this  approach. 

LISP.  Trace  specifications  could  be  translated  into  LISP  [4]  by  Phase  I  and  then  executed  in 
Phase  II.  Although  pure  LISP  can  be  considered  a  nonprocedural  language,  it  is  well  known  that  pro¬ 
gramming  in  pure  LISP  is  impractical.  Consequently,  this  approach  would  be  likely  to  encounter  the 
same  kinds  of  difficulties  as  translating  trace  specifications  into  a  procedural  language.  However,  we  are 
investigating  this  approach. 

Prolog.  In  this  case,  trace  specifications  must  be  translated  into  Prolog  [5]  notation  by  Phase  I  and 
then  executed  in  Phase  II.  The  syntax  of  Prolog  is  well-suited  for  this  purpose,  and  Prolog  includes  a 
theorem  prover  that  can  be  used  both  to  "execute"  the  specifications  and  to  attempt  to  prove  theorems 
about  them.  Prolog  is  the  target  language  in  our  chosen  approach;  more  details  are  provided  in  the 
next  section.  A  drawback  is  that,  despite  its  nonprocedural  look,  Prolog  behavior  does  depend  on  the 
order  in  which  facts  are  presented  (because  of  its  use  of  a  depth-first  search). 

Prolog  Variants.  Several  variants  of  Prolog  exist  that  may  be  as  well-suited  as  Prolog  for  express¬ 
ing  trace  specifications  and  that  may  solve  the  problems  caused  by  the  sensitivity  of  Prolog  to  fact¬ 
ordering.  Two  examples  are  LOGLISP  (6]  and  TABLOG  [7].  We  have  yet  to  evaluate  either  of  these 
fully. 


SNOBOL  or  Icon.  Icon  [8]  is  a  string  processing  language  descended  from  SNOBOL  [9],  An 
approach  based  on  either  SNOBOL  or  Icon  might  resemble  that  based  on  YACC:  an  Icon  program 
would  be  used  to  translate  a  trace  specification  into  an  Icon  program;  this  latter  program  would  then  be 
executed  with  specific  traces  as  input.  An  Icon  program  to  translate  traces  into  Prolog  was  written; 
translation  of  trace  specifications  into  Icon  has  not  been  attempted  as  yet. 

PROLOG 

Prolog  is  a  programming  language  based  on  Horn  clauses  [10].  A  Horn  clause  is  a  formula  of 
first-order  logic  that  is  of  the  form  (1)  Pfri.r^,. . .  where  P  is  an  n-place  predicate  and  each  is  a 
term,  of  the  form  (2)  . .  ,t„)  where  P  and  each  /,  are  as  above,  or  of  the  form  (3) 

C  V  ->P{t\,t2,-  ■  where  C  is  a  Horn  clause  and  P  and  each  t,  are  as  above.  Terms  can  either  be 

constants,  variables,  or  functions  of  other  terms.  All  variables  are  assumed  to  be  universally  quanti¬ 
fied.  A  Prolog  program  is  a  set  of  clauses  where  each  clause  is  of  the  first  or  the  third  form.  Clauses 
of  the  first  form  are  called  facts  and  written  as  they  are  in  first-order  logic  with  the  understanding  that 
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predicate  letters,  constants,  and  function  symbols  begin  with  small  letters,  and  variables  begin  with  cap¬ 
itals.  Clauses  of  the  third  form  are  called  rules  and  written  as  Fx  -  where  F\  is  the  single 

nonnegated  disjunct  of  the  clause.  F\  is  called  the  head  of  the  rule,  and  f  2  . . .  ,F„  is  the  tail.  A  clause 
that  is  either  a  fact  or  a  rule  is  called  a  program  clause. 

The  translation  from  trace  specifications  to  Prolog  appears  to  be  simple  enough  that  we  may  be 
able  to  use  YACC  to  generate  a  Phase  I  program  that  accepts  trace  specification  language  as  input  and 
generates  a  Prolog  program  as  output  for  execution  by  the  Prolog  interpreter  in  Phase  II,  as  shown 
below. 


trace 

YACC 
generated 
compiler 
(Phase  I) 

Prolog 

Prolog 
interpreter 
(Phase  n) 

specification 

specific 
trace  T 


L(T),V(T) 


The  stack  specification  translates  simply  into  the  Prolog  program  shown  below.  In  Prolog,  traces 
are  considered  as  lists  and  written  in  reverse  notation.  Hence,  PUSH (.n).  TOP  becomes  [top, push (n)]. 
The  empty  sequence  of  procedure  calls  is  denoted  by  [  ].  The  legality  predicate  is  written  leg,  and 
equiv  and  val  denote  =  ,  and  the  relational  form  of  V  ,  respectively.  Line  numbers  are  included  for 
future  reference. 


STACK  PROGRAM 


(1)  legd  I). 

(2)  leg(lpush(S)frl)  leg  (T). 

(3)  equiv((depth[rl,T). 

(4)  equiv  ([top, push  (S)fri,lpush  (S)frl) . 

(5)  equiv(|pop,push(S)fri,T). 

(6)  val(|top,push(S)frl,S)  leg  (T). 

(7)  vaKIdepthl.O). 

(8)  val(ldepth,push(S)fri,V)  val((depthfri,R),  V  Is  R  +  1,  leg(T). 

(9)  leg(T)  equiv  (T,S),  leg(S). 

(10)  valdltSI.V)  equiv(S,R),  valdT|Rl,V). 

(11)  equiv(X,Y)  equfv(A,B),  append(R,A,X),  append(R,BtY). 

(12)  equiv (S,T)  equiv (T,S). 

(13)  equiv(S,T)  equiv(S,A),  equiv(A,T). 

(14)  equiv  (S,S). 

(15)  appendd  l,L,L). 

(16)  append(|xjLll,L2,lXlL3l)  append(Ll,L2,L3). 

Clauses  (2)  to  (8)  are  Prolog  translations  of  semantic  assertions  (1)  to  (7)  of  the  trace  specification. 
The  remaining  clauses  are  common  to  all  programs  produced  by  our  system.  Clause  (1)  and  clauses 
(9)  to  (14)  are  translations  of  assertions  from  the  trace  deductive  system  as  described  in  Ref.  [1]. 
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Clauses  (15)  to  (16)  define  the  append  predicate  used  to  manipulate  the  list  representations  of  traces. 
The  reason  for  the  particular  order  of  clauses  is  discussed  in  the  next  section. 

To  illustrate  the  nonvariance  of  the  common  clauses,  we  include  a  translation  of  a  queue  specifi¬ 
cation. 


QUEUE  SPECIFICATION 


Syntax: 

ADD:  integer 
REMOVE: 

Front:  — >  integer 


Semantics: 

(1)  L(T)  —  L(T.ADD(n)) 

(2)  ADD(n). REMOVE  =  I  I 

(3)  T.ADD(n). FRONT  =  T.ADD(n) 

(4)  T.ADD(n).ADD(m). REMOVE  s  T.ADD(n).REMOVE.ADD(m) 

(5)  V(ADD(n). FRONT)  «  n 

(6)  L(T)  -  V(T.ADD(n).ADD(m). FRONT)  =  V(T.ADD(n). FRONT) 

QUEUE  PROGRAM 


(1)  legd  I). 

(2)  leg(ladd(S)fri)  :-  leg  (T). 

(3)  equiv ((remove,  add(S)l,  I  I  ). 

(4)  equivdfront,  add(S)frl,(add(S)fr(). 

(5) equiv  ((remove, add  (S)  ,add  (R)fr(,(add  (S)  ,remove,add(R)frl) , 

(6)  val ((front, add (S)I,S). 

(7)  val((front,add(S),add(R)rr(,X)  :-  val((front,add(R)fT(,X),  )eg(T). 

(8)  leg(T)  :- equiv (T,S),  leg(S). 

(9)  valdT$|,V)  :-  equiv(S,R),  val(ITtR|,V) 

(10)  equiv(X,Y)  :•  equiv(A,B),  append(R,A,X),  append(R,B,Y). 

(11)  equiv(S,T)  :-(T,S). 

(12)  equiv(S,T)  :-  equiv(S,A),  equiv(A,T). 

(13)  equiv(S,S). 

(14)  append((  (,L,L). 

(15)  append((XrLll,L2.(X|L3()  :-  append (L1,L2,L3). 

Given  such  a  program,  Prolog  tries  to  satisfy  assertions  when  prompted.  If  the  assertion  contains 
no  variables  and  can  be  derived  from  the  program,  yes  is  returned,  if  the  assertion  contains  variables 
and  there  are  constants  that  when  substituted  for  the  variables  of  the  assertion  make  the  assertion 
derivable,  these  constants  are  returned.  Otherwise,  Prolog  will  return  no  or  attempt  an  infinite  search 
for  a  derivation.  When  it  does  one  rather  than  the  other  is  examined  in  the  next  section. 

Queries  submitted  to  the  stack  program  are  illustrated  in  the  following  script  of  a  Prolog  session. 
Characters  typed  by  the  user  are  shown  in  boldface.  The  version  of  Prolog  used  is  C-Prolog  on  a  VAX 
operating  under  the  BSD  4.2  Unix  operating  system.  The  stack  program  is  contained  in  a  file  named 

stack. 
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PROLOG  SESSION  WITH  STACK 


CProlog  version  1.2a,  NRL-CSS 
1  ?-  (stack]. 

stack  consulted  1304  bytes  0.333333  sec. 
yes 

I  ?-leg((push(5)l). 


I  ?-equiv (Itop.push (5) I, (push (S)|,|push(S) I). 

yes 

I  ?-leg(ltop,push(5)l). 

yes 

I  ?-  val(ltop,push(S)l,5). 

yes 

I  ?-  val(ltop,push(S)],X). 

X  =  5 

yes 

I  ?-  hah. 

[Prolog  execution  halted] 

PROLOG  IMPLEMENTATIONS  OF  TRACE  SPECIFICATIONS 

In  our  discussion  of  Prolog  so  far,  we  have  glossed  over  several  issues  that  are  relevant  to  regard¬ 
ing  Prolog  programs  as  implementations  of  trace  specifications.  First,  we  have  not  said  what  trace 
assertions  can  be  cast  as  Prolog  program  clauses.  Second,  we  have  not  said  when  a  clause  is  derivable 
from  a  Prolog  program.  We  address  these  issues  in  this  section. 

It  is  well  known  that  any  formula  of  first-order  logic  (and  hence,  any  trace  assertion)  is  equivalent 
to  a  formula  (01)  ...  (Qn)F,  called  its  prenex  diyunctive  form,  where  each  (Qi)  is  a  quantifier  and  F  is 
a  disjunction  of  either  atomic  formulae  or  their  negations.  Such  a  formula  is,  in  fact,  a  Prolog  program 
clause  if  (1)  no  (Qi)  is  an  existential  quantifier,  and  (2)  F  contains  at  least  one  nonnegated  disjunct 
and  at  most  one  negated  disjunct.  Condition  (1)  is  not  problematic  since  a  formula  containing  an 
existential  quantifier  is  cosatisfiable  with  a  formula,  called  a  Skolem  formula,  that  contains  only  univer¬ 
sal  quantifiers  with  some  additional  function  symbols  [II].  Hence,  eliminating  existential  quantifiers 
from  a  prenex  formula  does  not  alter  what  we  can  derive  from  that  formula.  Condition  (2),  however, 
presents  more  serious  troubles.  A  formula  whose  prenex  disjunctive  form  contains  too  few  nonnegated 
disjuncts  or  too  many  negated  disjuncts  can  be  converted  to  a  program  clause  by  using  the  Prolog  predi¬ 
cate  not  which  has  the  property  that  not(F)  is  Prolog-derivable  if  and  only  if  an  attempt  to  derive  F  in 
Prolog  leads  to  a  return  of  no.  Hence,  we  can  write  -C(r)  as  not  (G(f))  and  F(t)  V  Git)  as 
Fit).-not(H(t))  if  we  can  define  a  predicate  H  such  that  Git)  is  Prolog-derivable  if  and  only  if  Hit) 
is  refutable.  However,  converting  a  prenex  formula  to  a  program  clause  in  this  way  often  results  in  a 
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loss  of  derivational  power.  To  understand  this  limitation  on  using  not  we  must  consider  what  it  means 
for  something  to  be  Prolog-derivable,  i.e.,  we  must  give  a  semantics  for  Prolog.' 

Call  5  a  substitution  if  it  is  an  assignment  of  constants  to  variables.  We  denote  the  result  of  apply¬ 
ing  S  to  a  formula  T  by  TiS.  Given  a  predicate  F  and  a  constant  c,  F(c)  is  refutable  by  a  Prolog  pro¬ 
gram  f*  if  (1)  there  are  no  occurrences  of  F(c)  or  F(X)  in  P  for  any  variable  T,  (2)  any  rule  of  the 

form  F(c):-Ti . T„  in  P  is  such  that  each  fact  in  the  set  (Ti/S,  ...,T„/S}  is  refutable  by  P  for  any 

assignment  5,  and  (3)  any  rule  of  the  form  F{X).-T\ . T„  in  P  is  such  that  each  fact  in  the  set 

[Tf  S,  . .  .,T„I S]  is  refutable  by  P  for  any  assignment  S  that  assigns  c  to  A".  We  say  that 
F(c)  is  derivable  from  P  if  (1)  there  appears  in  /*  a  program  statement  of  the  form 

F(c), 

FIX), 

F{c):—T\ _ T„  where  each  fact  in  the  set  {TfS,. . .  ,r„/S]  is  derivable  from  P  for  some 

assignment  S,  or 

F(X):-  r,,. . . ,  where  each  fact  in  the  set  {  FfS,. . .  ,F„/Sl  is  derivable  from  P  for  some 
assignment  5  that  assigns  c  to  Af; 

and  (2)  F(c)  is  refutable  by  that  part  of  P  that  precedes  that  fact  cited  in  (1).  Given  a  query  of  the 
form  Fic).  Prolog  will  answer  yes  if  F(c)  is  derivable  from  P,  will  answer  no  if  F(c)  is  refutable  by 
P,  and  will  fail  to  answer  otherwise.^ 

From  this  discussion  we  can  see  that  although  any  trace  specification  may  have  a  sound  Prolog 
implementation,  i.e.,  an  implementation  that  does  not  return  incorrect  answers  to  queries,  not  every 
sound  implementation  of  a  specification  is  complete.  Many  implementations  may  not  return  an  answer 
to  a  query  even  though  there  is  an  answer  that  can  be  logically  derived  from  the  specification. 

One  source  of  incompleteness  is  obviously  the  use  of  not  since  we  may  not  be  able  to  refute  the 
assertion  being  negated;  however,  this  is  not  the  only  source.  An  examination  of  our  initial  stack  pro¬ 
gram  shows  that  claims  of  the  form  equivftracel, trace!)  are  not  refutable.  This  is  because  of  the  pres¬ 
ence  of  axioms  (11)  to  (14)  whose  heads  will  always  be  satisfied  by  the  query.  Since  axiom  (9)  for 
legality  and  axiom  (10)  for  values  appeal  to  the  notion  of  equivalence,  legality  assertions  and  value 
assertions  are  also  not  refutable. 

On  a  more  positive  note,  incomplete  programs  can  often  be  made  complete.  For  example,  we  can 
solve  the  problem  with  our  stack  program  by  dropping  the  troublesome  axioms  and  adjusting  the  rest  of 
the  program  to  compensate.  Note  that  axioms  (12)  to  (14)  serve  only  to  ensure  that  equivalence  is  an 
equivalence  relation.  This  is  necessary  to  be  able  to  determine  correctly  whether  two  traces  are 
equivalent  simpliciter,  but  it  is  not  necessary  for  determining  legality  or  values.  For  example,  we  can 
derive  leg(ldepth,depth,push(l)l)  from  leg((push(l)|)  by  using  (3)  to  derive  equiv  ((depth, depth 
push(])l,ldepth,pusb(l)l)  and  equiv  (Idepth.pushd)  l,lpush(l)l)  without  having  to  appeal  to  the  fact 


I.  Wc  ignore  the  Prolog  predicate  cui  ISI  since  although  it  is  used  to  improve  efTiciency  of  Prolog  derivations,  it  does  not 
increase  the  set  of  derivable  facts.  The  following  discussion  can  be  extended  to  include  cut  by  considering  the  order  of  facts 
within  a  rule's  tail  as  well  as  the  order  of  clauses  within  a  program. 

2  The  response  to  a  query  of  the  form  F(X)  can  be  determined  by  considering  queries  of  the  form  F(c)  v'here  c  is  a  member  of 
the  Herbrand  Universe  (101  of  P. 
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that  equivddepth, depth, push(l)|,|push(l)l).  Hence,  we  can  drop  axioms  (12)  to  (14)  without  affect¬ 
ing  the  program's  behavior  with  respect  to  legality  or  values.  Axiom  (11)  serves  a  different  purpose.  It 
allows  us  to  look  for  equivalent  traces  within  traces  and  replace  them.  However,  we  can  eliminate  this 
axiom  by  redefining  equivalence  in  our  specification.  Hence,  consider  the  following  stack  specification: 

STACK  SPECIFICATION 

Syntax: 

PUSH:  integer 

POP: 

TOP:— >  integer 

DEPTH:— >  integer 

Semantics: 

(1)  L(T)  -  L(T.  PUSH(n)) 

(2)  T.DEPTH.S  =  T.S 

(3)  T.PUSH(n).TOP.S  =  T.PUSH(n).S 

(4)  T.PUSH(n).POP.S  =  T.S 

(5)  L(T)  -  V(T.PUSH(n).TOP)  =  n 

(6)  V(DEPTH)  =  0 

(7)  L(T)  —  V(T.PUSH(n). DEPTH)  =  1  +  V(T.DEPTH) 


We  have  modified  axioms  (2)  to  (4)  to  make  explicit  the  fact  that  equivalent  traces  can  be  substi¬ 
tuted  within  a  trace.  From  the  viewpoint  of  logical  derivation  this  modification  changes  nothing,  but 
from  the  view  cf  Prolog,  it  enables  us  to  drop  a  troublesome  axiom  from  oui  program.  Hence,  we 
have  the  following  implementation: 


STACK  PROGRAM 


(1)  leg  (I  I  ). 

(2)  leg([push(S)|TI)  :-  leg(T). 

(3)  val(ltop,pusb(S)T|,S)  :- leg(T). 

(4)  vaKIdepthl.O). 

(5)  vai(ldepth,push(S)frl,V)  :-  valddepthfTKR),  V  is  R  +  1,  leg(T). 

(6)  equiv(A,B)  :-  append(ldepthl,Ll,T),  append(H,T,A),  append  (H,L1,B). 

(7)  equiv(A,B)  :-  append(ltop,push(N)|,Ll,T),  append (H,T, A), 

append(lpush(N)l,Ll,L2),  append(H,L2,B). 

(8)  equiv(A,B)  :-  append(lpop,push(S)l,Ll,T),  append  (H,T,A),  append(H,Ll,B). 

(9)  leg(T)  :.  equlv(T,S),leg(S). 

(10)  val(|T|SI,V)  :-  equlv(S,R),  valdTtRI.V). 

(11)  appendd  1,L,L). 

(12)  append(|\^ll,L2,lX|L3l)  :-  append(Ll,L2,L3). 

This  implementation  derives  all  the  legality  and  value  assertions  that  the  other  derives,  but  it  also 
refutes  assertions  involving  false  legality  and  value  claims.  It  is  inferior  to  the  first  implementation  in 
that  we  can  no  longer  derive  equiv(a,b)  from  equiv(a,c)  and  equiv(c,b),  but  equivalence  is  important 
primarily  in  the  role  it  plays  in  specifying  legality  and  values.  Further,  we  can  define  a  notion  of  transi¬ 
tive  equivalence  if  we  like  by  adding  the  following  axioms: 
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(13)  teq'iiv(A,A). 

(14)  te(juiv(A,B)  equiv(A,B). 

(15)  tequiv(A,B)  tequiv(A,C),  tequiv(C,B)- 

Summarizing,  our  semantics  has  enabled  us  to  determine  that  a  program  is  incomplete  and  isolate 
the  cause  of  the  incompleteness.  By  rewriting  the  program,  we  have  rendered  it  complete,  but  at  the 
cost  of  not  being  able  to  derive  any  equivalence  assertions  that  depend  on  the  transitive  closure  of 
equivalence .  This  does  not  bother  us  since  we  are  rarely  interested  in  equivalence  assertions  per  se,  but 
only  in  so  far  as  they  contribute  to  the  derivation  of  legality  and  value  assertions. 

CONCLUSIONS 

We  conclude  that  Prolog  warrants  further  research  as  a  target  language  for  a  trace  implementation 
system.  It  is  possible  to  translate  a  trace  specification  into  a  sound  Prolog  implementation  although 
care  must  be  taken  in  formulating  the  specification  if  we  are  to  avoid  incomplete  programs.  Further, 
translation  can  probably  be  done  mechanically  although  it  is  not  clear  that  there  is  a  mechanical  pro¬ 
cedure  that  will  always  yield  a  complete  program.  Nevertheless,  we  have  been  able  to  isolate  a  major 
cause  of  incompleteness  in  translated  programs  and  have  shown  a  method  for  writing  specifications  that 
eliminates  this  cause.  Work  must  proceed  to  see  how  far  this  method  can  be  generalized.  We  are 
interested  in  whether  all  specifications  can  be  formulated  to  yield  complete  programs  and  if  not, 
whether  we  can  describe  those  that  cannot  be  so  formulated. 

In  the  meantime  we  are  also  working  on  other  approaches.  We  have  had  some  success  with  LISP. 
It  is  possible  that  the  two  approaches  may  complement  each  other  even  if  neither  is  completely  success¬ 
ful.  In  this  case,  a  combination  of  Prolog  and  LISP,  such  as  is  found  in  LOGLISP,  could  prove  an  ideal 
language. 
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